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1.  INTRODUCTION 


Future  Anny  software  systems  will  continue  to  increase  in  cmnplexity  as  long  as  Army  hardware 
continues  to  get  more  sophisticated  and  mission  needs  more  challenging.  Life-cycle  costs  for  these 
systems  will  continue  to  rise.  It  is  estimated  that  life-cycle  costs  of  the  over  350  software  systems  that 
the  U.S.  Army  Materiel  Command  is  currently  responsible  for  will  exceed  $35  billioa  The  maintenance 
costs  for  these  systems  is  estimated  at  between  $17-25  l^on  (Piersall  1994).  Current  software 
development  and  maintenance  practice  will  soon  become  insufBcient  to  handle  the  evolution  of  this 
software  at  a  reasonable  cost;  hence,  more  reliable  and  efficient,  computer-aided  methods  must  be  adopted 
in  order  to  keep  pace. 

One  such  method  is  computer-aided  prototyping.  This  method  not  only  improves  software 
development  activities  but  benefits  software  maintenance  as  well.  The  benefits  provided  by 
computer-aided  prototyping  m  software  maintenance  start  in  the  initial  phases  of  system  development 
If  current  methods  are  used  to  develop  and  maintain  this  software,  software  costs  will  continue  to  rise,  thus 
counteracting  the  decreasing  budget  trend.  What  we  need  are  software  development  and  maintenance 
methods  which  take  advantage  of  automation  and  decrease  costly  human  involvement. 

Computer-aided  prototyping  is  one  such  method  that  reduces  initial  development  time  while  allowing 
the  development  software  to  be  maintained  using  the  same  prototyping  tools.  In  computer-aided 
prototyping,  quickly  built  and  iteratively  updated  prototypes  of  the  intended  system  are  demtHistrated  to 
the  user.  Each  successive  iteration  of  the  prototype  resembles  more  closely  the  final  intended  versiwi  of 
the  software.  The  final  accepted  prototype  is  a  very  close  approximation  of  the  intended  software  system. 
Since  the  prototype  is  written  in  a  specification  language  translatable  to  a  high-level  programming 
language  such  as  Ada,  the  code  produced  by  the  prototyping  environment  can  be  used  in  the  final  software 
product 

This  same  prototyping  environment  can  also  be  used  to  perform  maintenance  on  a  production  version 
of  a  software  system.  Since  translation  mechanisms  may  also  be  used  to  translate  high-level  programming 
code  into  the  prototyping  language  (Altizer  and  Berzins  1992),  a  production  version  of  the  software  system 
can  be  translated  into  the  prototyping  language,  loaded  into  the  prototyping  environment,  updated,  and 
translated  back  into  the  high-level  programming  language.  This  is  useful  because  the  prototype  descriptitm 
is  significantly  simpler  than  the  production  code  if  the  prototype  is  expressed  in  a  notation  tailored  to 
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support  modifications.  In  addition,  the  software  tools  in  the  computer-aided  prototyping  environment  can 
help  cany  out  the  required  modifications  rapidly  (Luqi  1989).  This  research  impacts  both  of  these  roles 
for  raiMd  prototyping.  We  concentrate  on  plication  of  this  technology  to  software  maintenance,  since 
the  majority  of  maintenance  costs  are  associated  with  enhancement  and  refinement  rather  than  correcting 
faults  (Rersall  1994). 

2.  CHANGE-MERGING 

Change-merging  is  the  process  of  automatically  combining  the  effects  of  several  changes  to  a  software 
system  (Dampier,  Luqi,  and  Berzins  1994).  Eariy  version  control  systems  such  as  the  source  code  control 
system  (SCCS)  (Silveiberg  1992)  and  the  revision  control  system  (RCS)  (Tichy  1982)  provide  primitive 
change-merging  facilities  based  cm  string  editing  operations  on  the  source  text  without  considering  the 
effects  on  program  behavior.  However,  autcmiated  tools  must  provide  guarantees  to  designers  regarding 
program  behavior.  Semantics-based  change-merging  seeks  to  construct  a  program  whose  behavior  contains 
all  of  the  significant  changes  made  in  the  modified  versions  while  maintaining  any  behavior  common  to 
all  three  versions. 

We  have  constracted  a  model  and  algorithm  for  automatically  rqxlating  different  versions  of  a  software 
prototype  with  changes  made  to  the  base  version  as  shown  in  Figure  1.  These  changes  are  applied  to  the 
base  version  and  propagated  through  all  of  the  different  production  versions  by  using  the  change-merging 
algorithm.  This  algorithm  accepts  a  base  version  and  two  modified  versions  of  the  program  and  uses 
program  slicing  (Weiser  1984)  to  find  the  part  of  the  base  version  preserved  in  both  of  the  modifications, 
as  well  as  the  parts  of  the  modifications  which  are  different  finom  the  base.  The  algorithm  then  comlnnes 
these  three  pieces  into  a  merged  program  containing  the  fiinctionality  peculiar  to  each  of  the  modified 
versions.  This  method  is  apfdied  to  the  change  propagatirm  problem  by  using  the  base  version  of  the 
program  as  the  base  for  the  diange-merge,  the  production  version  to  be  updated  as  one  modification,  and 
the  changed  base  version  as  the  other  modification  as  shown  in  figure  2.  As  long  as  the  change  made 
to  the  base  does  not  conflict  with  the  production  version,  the  result  will  be  an  updated  production  version 
containing  both  its  original  functionality  and  the  update. 

A  wotkirig  version  of  this  change-merge  algorithm  has  been  developed  for  the  computer-aided 
prototyping  system  (CAPS)  (Luqi  1989),  using  the  prototyping  system  description  language  (PSDL)  (Lu^ 
1988)  as  its  base  language. 
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Algorithm  Change-Merge(BASE,  A,  B  :  psdl_program)  return  psdlj)rogram  is 
begin 

Change-Meige  the  Specifications; 

—Each  individual  component  of  the  specification  is  change-meiged  according  to  the  rules 
defined 

--by  Dampier  (1990,  1994). 

Qiange-Meige  the  Gr^hs; 

Build  Prototype  Dependence  Graphs  for  each  version; 

Calculate  the  Preserved  Part  of  BASE  in  both  A  and  B; 

Calculate  the  Affected  Part  of  both  A  and  B  with  re^ct  to  Base; 

Gra[di-Union  the  Preserved  Part  with  the  Affected  Parts  of  both  A  and  B; 

Check  Correctness  of  Merge  using  Compare  Gnq)hs; 

Change-Merge  the  remainder  of  the  Implementations; 

—The  stream  and  timer  declarations  along  with  the  control  constraints  are  merged  according  tt) 
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graph  with  respect  to  a  set  of  its  data  streams.  The  slice  captures  only  that  portion  of  the  prototype  that 
can  possibly  affect  the  values  written  to  one  of  those  streams. 

A  prototype  dependence  gra^i  (PDG)  for  a  prototype  P  is  an  augmented,  fully  expanded,  PSDL 
implementation  graph  Gp  =  (V,  E,  Q.  The  set  of  vertices,  V,  has  been  augmaited  with  an  external  vertex, 
EXT.  The  set  of  edges,  E,  has  been  augmented  with  an  edge  from  each  vertex  without  an  outgoing  edge 
to  the  EXT  vertex.  Furthermore,  a  timer  dependency  edge  is  added  finom  Vj  to  Vj  when  Vj,  Vj  e  V  and  Vj 
ccmtains  timer  operations  that  affect  the  state  of  a  PSDL  timer  read  by  Vj.  A  slice  of  a  PSDL  prototype 
P  with  respect  to  a  set  of  streams  X,  Sp  (X)  =  (V,  E,  C),  is  a  subgraph  of  the  PDG,  Gp,  which  includes 
the  part  of  P  affecting  the  values  written  to  that  set  of  data  streams.  A  slice  is  constructed  as  follows: 

(1)  V  is  the  smallest  set  that  contains  all  vertices  Vj  e  Gp  that  satisfy  at  least  one  of  the  following 
conditicxis: 

(a)  Vj  writes  to  one  of  the  data  streams  in  X. 

(b)  Vj  precedes  Vj  in  Gp,  and  Vj  e  V. 

(2)  E  is  the  set  that  contains  all  of  the  data  streams  Gp  which  satisfy  one  of  the  following 
conditions: 

(a)  Xj^  e  X. 

(b)  x,^  is  directed  to  some  Vj  e  V. 

(3)  C  is  the  set  that  contains  all  of  the  timing  and  control  constraints  associated  with  each  operator 
in  V  artd  each  data  stream  in  E. 

An  example  of  a  PDG  is  shown  in  Figure  3.  This  graph  is  the  implementation  gr^h  for  a  prototype 
of  the  Patriot  missile  defense  system.  This  prototype  has  five  operators  and  eight  streams.  A  slice  of  this 
operator  taken  with  respect  to  one  of  those  streams  will  contain  everything  in  the  prototype  fliat  affects 
the  values  written  to  that  stream.  An  example  of  the  slice  of  this  prototype  with  respect  the  stream 
tactical_status  is  shown  in  Figure  4. 
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Figure  3.  PPG  for  ttie  Patriot  missile  defense  system,  version  1.1. 


Figure  4.  The  slice  of  Patriot’s  PDG  with  respect  to  the  stream  tactical _status. 

Slices  are  valuable  in  change-merging  because  they  partition  the  prototype  into  disjoint  parts  that  can 
be  considered  in  isolation  without  worrying  about  the  rest  of  the  prototype.  This  guarantees  that  a  slice 
taken  from  one  prototype  and  placed  in  another  where  that  slice  is  still  well-formed  will  behave  in 
precisely  the  same  way  as  it  did  in  the  first  prototype  (Dampier,  June  1994). 
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4.  SLICING  METHOD  FOR  CHANGE-MERGING  OF  PROTOTYPES 


We  use  prototype  slicing  for  change-meiging  in  much  the  same  way  program  slicing  was  used  in 
Horwitz  integration  method  (Horwitz,  Prins,  and  Reps  1988).  We  use  slicing  to  calculate  the  preserved 
part  of  the  base  version  and  affected  parts  of  each  modified  version  when  performing  a  semantics-based 
change-merge  of  three  versions  of  a  prototype. 

Consider  two  modified  versions  of  the  base  Patriot  prototype.  Version  1.1,  shown  in  Figure  3.  The 
first  modified  version,  1.2,  shown  in  Figure  5,  is  one  in  which  a  modified  version  of  the  control_Patriot 
module  has  been  installed  in  a  working  system.  The  second  modified  version,  2.2,  shovm  in  Figure  6, 
is  a  copy  of  the  base  in  which  the  display_states  module  has  been  updated.  The  preserved  part  of  the  base 
version  of  the  prototype  is  determined  by  finding  the  largest  slice  common  to  all  three  versions.  In  the 
Patriot  system  example,  this  is  the  slice  of  Patriot’s  PDG  with  respect  to  the  following  set  of  streams: 
{radar_mode,  trackjd,  missile.track,  intercept_angle,  taiget_range,  tactical_stams,  launch_angle,  track_file, 
launch_Patriot_ext}.  A  picture  of  this  slice  is  shown  in  Figure  7. 


Figures.  PDG  for  the  Patriot  missile  defense  system,  version  1.2. 
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Figure  6.  PPG  for  the  Patriot  missile  defense  system,  version  2.2. 


Figure  7.  Preserved  part  of  the  PPG  for  versions  1.1.  1.2.  and  2.2  of  the  Patriot  system. 

The  affected  parts  of  the  two  modified  versions  are  computed  by  comparing  the  base  version.  Figure  3, 
with  the  modifications,  Figures  5  and  6.  This  comparison  is  done  using  prototype  slicing.  If  the  slice  of 
a  modified  version  with  respect  to  a  set  of  streams  is  different  than  the  same  slice  of  the  base  version,  then 
those  streams  are  affected  parts.  Any  change  between  the  base  and  the  modified  versions  is  significant 
and  must  be  included  in  the  affected  part  for  that  modificafitm.  The  affected  parts  of  the  two  modified 
versions  of  the  Patriot  prototype  are  shown  in  Figures  8  and  9. 
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Figure  8.  Affected  part  of  ihe  PPG  for  version  1.2  of  tfie  Patriot  system. 


Figure  9.  Affected  part  of  the  PPG  for  version  2.2  of  the  Patriot  system. 

In  our  algorithm,  the  change-merged  version  is  built  by  combining  the  preserved  part  with  each  of  the 
affected  parts  using  a  graph-union  operatioa  The  result  of  applying  the  change-merge  operation  to  the 
three  versions,  1.1, 1.2,  and  2.2,  of  the  Patriot  prototype  is  shown  in  Figure  10.  This  is  a  change-merged 
version  of  the  graph  but  is  not  yet  guaranteed  to  be  semantically  correct.  The  semantic  correctness  is 
guaranteed  only  after  the  change-merged  version  is  compared  with  each  of  the  modified  versions  to  ensure 
that  any  changes  made  in  the  modified  versions  are  preserved  during  the  change-merge  operation. 

We  check  for  correcmess  by  comparing  the  slices  of  both  the  modified  version  and  the  change-merged 
version  with  respect  to  the  streams  in  the  affected  part  for  that  modified  version.  If  the  slices  are  the 
same,  then  we  are  guaranteed  to  have  preserved  the  semantic  mearung  sigmficant  to  the  modified  version. 
If  the  slices  are  different,  then  a  conflict  has  occurred  between  the  two  modified  versions  that  must  be 
resolved  by  the  engineer. 
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Figure  10.  Result  of  change-merging  versions  1.1.  1.2.  and  2.2  of  the  Patriot  system. 

5.  SUMMARY 

We  have  described  a  formal  method  that  can  significantly  improve  both  die  software  develo^ent  and 
software  maintenance  processes.  The  method  provides  the  ability  for  software  development  teams  to  work 
on  independent  parts  of  a  software  project  and  use  a  computer-aided  tool  to  automatically  integrate  their 
respective  updates.  This  method  can  significantly  decrease  development  time,  thereby  improving  customer 
satisfaction  with  the  delivered  system.  This  method  can  also  be  used  to  update  different  production 
versions  of  a  software  system  by  allowing  changes  to  be  made  to  the  base  version  and  automatically 
change-merged  with  each  of  the  versions  in  the  field.  Use  of  this  method  will  decrease  both  software 
development  and  maintenance  costs  by  providing  the  software  engineer  with  a  reliable  computer-aided  tool 
to  decrease  their  workload. 

Future  enhancements  to  this  research  include  considering  abstract  data  types  written  in  the  prototyping 
language,  finding  ways  to  resolve  more  conflicts  automatically,  and  developing  methods  to  change-merge 
programs  written  in  implementation  languages  like  Ada  and  C-H-. 
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